[Fizz] escape <style> textContent as css #28870
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
style text content has historically been escaped as HTML which is non-sensical and often leads users to using dangerouslySetInnerHTML as a matter of course. While rendering untrusted style rules is a security risk React doesn't really provide any special protection here and forcing users to use a completely unescaped API is if anything worse. So this PR updates the style escaping rules for Fizz to only escape the text content to ensure the tag scope cannot be closed early. This is accomplished by encoding "s" and "S" as hexadecimal unicode representation "\73 " and "\53 " respectively when found within a sequence like </style>. We have to be careful to support casing here just like with the script closing tag regex for bootstrap scripts.
facebook-github-bot
added
CLA Signed
React Core Team
|
Comparing: 4c34a7f...a61a35d Critical size changesIncludes critical production bundles, as well as any change greater than 2%:
Significant size changesIncludes any change greater than 0.2%: Expand to show
|
kassens
reviewed
Apr 18, 2024
| prefix: string, | ||
| s: string, | ||
| suffix: string, | ||
| ) => `${prefix}${s === 's' ? '\\73 ' : '\\53 '}${suffix}`; |
There was a problem hiding this comment.
should there be the spaces here? Not exactly sure how that escaping works. '\\73 '
There was a problem hiding this comment.
Yes. That’s how the end of the escape sequence is encoded in CSS. It should be exactly one.
sebmarkbage
approved these changes
Apr 19, 2024
github-actions bot
pushed a commit
that referenced
this pull request
Apr 19, 2024
style text content has historically been escaped as HTML which is non-sensical and often leads users to using dangerouslySetInnerHTML as a matter of course. While rendering untrusted style rules is a security risk React doesn't really provide any special protection here and forcing users to use a completely unescaped API is if anything worse. So this PR updates the style escaping rules for Fizz to only escape the text content to ensure the tag scope cannot be closed early. This is accomplished by encoding "s" and "S" as hexadecimal unicode representation "\73 " and "\53 " respectively when found within a sequence like </style>. We have to be careful to support casing here just like with the script closing tag regex for bootstrap scripts. DiffTrain build for [aead514](aead514)
gnoff
added a commit
that referenced
this pull request
Apr 19, 2024
stacked on #28870 inline script children have been encoded as HTML for a while now but this can easily break script parsing so practically if you were rendering inline scripts you were using dangerouslySetInnerHTML. This is not great because now there is no escaping at all so you have to be even more careful. While care should always be taken when rendering untrusted script content driving users to use dangerous APIs is not the right approach and in this PR the escaping functionality used for bootstrapScripts and importMaps is being extended to any inline script. the approach is to escape 's' or 'S" with the appropriate unicode code point if it is inside a <script or </script sequence. This has the nice benefit of minimally escaping the text for readability while still preserving full js parsing capabilities. As articulated when we introduced this escaping for prior use cases this is only safe because we are escaping the entire script content. It would be unsafe if we were not escaping the entirety of the script because we would no longer be able to ensure there are no earlier or later <script sequences that put the parser in unexpected states.
github-actions bot
pushed a commit
that referenced
this pull request
Apr 19, 2024
stacked on #28870 inline script children have been encoded as HTML for a while now but this can easily break script parsing so practically if you were rendering inline scripts you were using dangerouslySetInnerHTML. This is not great because now there is no escaping at all so you have to be even more careful. While care should always be taken when rendering untrusted script content driving users to use dangerous APIs is not the right approach and in this PR the escaping functionality used for bootstrapScripts and importMaps is being extended to any inline script. the approach is to escape 's' or 'S" with the appropriate unicode code point if it is inside a <script or </script sequence. This has the nice benefit of minimally escaping the text for readability while still preserving full js parsing capabilities. As articulated when we introduced this escaping for prior use cases this is only safe because we are escaping the entire script content. It would be unsafe if we were not escaping the entirety of the script because we would no longer be able to ensure there are no earlier or later <script sequences that put the parser in unexpected states. DiffTrain build for [561c023](561c023)
This was referenced Apr 24, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
style text content has historically been escaped as HTML which is non-sensical and often leads users to using dangerouslySetInnerHTML as a matter of course. While rendering untrusted style rules is a security risk React doesn't really provide any special protection here and forcing users to use a completely unescaped API is if anything worse. So this PR updates the style escaping rules for Fizz to only escape the text content to ensure the tag scope cannot be closed early. This is accomplished by encoding "s" and "S" as hexadecimal unicode representation "\73 " and "\53 " respectively when found within a sequence like </style>. We have to be careful to support casing here just like with the script closing tag regex for bootstrap scripts.